DXL Code for Attributes

Hello,

I got in the situation that I need to set manually the new req. id which unfortunately is a Object Identifier and to keep in the same time the old identifiers for tracing reasons. For that I found a solution on the forum (thanks to author Mathias Mamsch) see below, but I have no experience in writing this "small" code.
Any help will be appreciated.

Thanks and Regards

Daniel

"Chances are that your requirement ID is 'Object Identifier' and that is the reason you want to get back your old ones. In this case you might want to try to introduce a new attribute "Manual Identifer" and a "DXL Identifier". The DXL Identifier will be a DXL attribute that will contain the 'Manual Identifier' if it is present, otherwise the Object Identifier. Then you can set the manual identifier of the objects to the values they need to have and use the DXL Identifier instead of 'Object Identifier'. This will allow you to correct your identifiers in cases like these. "
Danio - Fri Sep 28 10:36:48 EDT 2012

Re: DXL Code for Attributes
Mathias Mamsch - Fri Sep 28 11:22:00 EDT 2012

Well the general idea is, that you introduce a new string attribute (e.g. Manual ID) to your module (scope: object), that can contain a manual requirement identifier. Then normally a DXL attribute (e.g. DXL Identifier) for a requirement identifier could look like this:
  

// normally there is an attribute which identifies requirements
// if you got some, you need to adapt the below commented out code 
 
// only show an ID for requirements:
// string sRequirementType = obj."Requirement Type"
// if (sRequirementType != "Requirement") halt 
 
// read the manual identifier attribute
string sManualIdentifier = probeAttr_ (obj, "Manual ID")
if (!null sManualIdentifier) { 
   // if we got a manual identifier show the manual identifier
   obj.attrDXLName = sManualIdentifier
} else {
   // show the DOORS identifier 
   obj.attrDXLName = (identifier obj) 
}

 


I hope you get the idea. This way works if you just want to manually correct the requirement identifier for a couple of existing objects, but keep using the DOORS identifier for others, e.g. you import a document which renumbers your DOORS identifiers, but you have a set of original identifiers you want to use. You need to be aware though, that newly created DOORS identifiers could collide with the ones you manually assigned and of course you could have a collision in the manually assigned identifiers too. So this is the general drawback when you introduce manual identifiers. If you plan to use DOORS identifiers mixed with manual identifiers like shown above you need to be sure that the generated DOORS identifiers will be larger than all manually created identifiers. Hope this helps, regards, Mathias

 

 

 

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

 

 

Re: DXL Code for Attributes
Danio - Mon Oct 01 08:34:17 EDT 2012

Mathias Mamsch - Fri Sep 28 11:22:00 EDT 2012

Well the general idea is, that you introduce a new string attribute (e.g. Manual ID) to your module (scope: object), that can contain a manual requirement identifier. Then normally a DXL attribute (e.g. DXL Identifier) for a requirement identifier could look like this:
  

// normally there is an attribute which identifies requirements
// if you got some, you need to adapt the below commented out code 
 
// only show an ID for requirements:
// string sRequirementType = obj."Requirement Type"
// if (sRequirementType != "Requirement") halt 
 
// read the manual identifier attribute
string sManualIdentifier = probeAttr_ (obj, "Manual ID")
if (!null sManualIdentifier) { 
   // if we got a manual identifier show the manual identifier
   obj.attrDXLName = sManualIdentifier
} else {
   // show the DOORS identifier 
   obj.attrDXLName = (identifier obj) 
}

 


I hope you get the idea. This way works if you just want to manually correct the requirement identifier for a couple of existing objects, but keep using the DOORS identifier for others, e.g. you import a document which renumbers your DOORS identifiers, but you have a set of original identifiers you want to use. You need to be aware though, that newly created DOORS identifiers could collide with the ones you manually assigned and of course you could have a collision in the manually assigned identifiers too. So this is the general drawback when you introduce manual identifiers. If you plan to use DOORS identifiers mixed with manual identifiers like shown above you need to be sure that the generated DOORS identifiers will be larger than all manually created identifiers. Hope this helps, regards, Mathias

 

 

 

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

 

 

Hello Mathias,

this is exactly what I would like to do. And it's working, thank you . The only issue is that the change of Attribute of the requirement to DXL ID is not persistent, at the next open of the module I still have the Object Identifier in properties of that column. Maybe has to do something with the rights ... or particularity of the Object Identifier, I do not know yet.

Thanks and Kind Regards

Daniel

Re: DXL Code for Attributes
Danio - Mon Oct 01 09:17:01 EDT 2012

Danio - Mon Oct 01 08:34:17 EDT 2012
Hello Mathias,

this is exactly what I would like to do. And it's working, thank you . The only issue is that the change of Attribute of the requirement to DXL ID is not persistent, at the next open of the module I still have the Object Identifier in properties of that column. Maybe has to do something with the rights ... or particularity of the Object Identifier, I do not know yet.

Thanks and Kind Regards

Daniel

Hello Mathias,

the issue with the Attribute persistence is solved too now.
The DXL code is running fine, I can now continue numbering as I want keeping the existing ones untouched.

Thank you

Daniel

Re: DXL Code for Attributes
llandale - Mon Oct 01 13:53:52 EDT 2012

Mathias Mamsch - Fri Sep 28 11:22:00 EDT 2012

Well the general idea is, that you introduce a new string attribute (e.g. Manual ID) to your module (scope: object), that can contain a manual requirement identifier. Then normally a DXL attribute (e.g. DXL Identifier) for a requirement identifier could look like this:
  

// normally there is an attribute which identifies requirements
// if you got some, you need to adapt the below commented out code 
 
// only show an ID for requirements:
// string sRequirementType = obj."Requirement Type"
// if (sRequirementType != "Requirement") halt 
 
// read the manual identifier attribute
string sManualIdentifier = probeAttr_ (obj, "Manual ID")
if (!null sManualIdentifier) { 
   // if we got a manual identifier show the manual identifier
   obj.attrDXLName = sManualIdentifier
} else {
   // show the DOORS identifier 
   obj.attrDXLName = (identifier obj) 
}

 


I hope you get the idea. This way works if you just want to manually correct the requirement identifier for a couple of existing objects, but keep using the DOORS identifier for others, e.g. you import a document which renumbers your DOORS identifiers, but you have a set of original identifiers you want to use. You need to be aware though, that newly created DOORS identifiers could collide with the ones you manually assigned and of course you could have a collision in the manually assigned identifiers too. So this is the general drawback when you introduce manual identifiers. If you plan to use DOORS identifiers mixed with manual identifiers like shown above you need to be sure that the generated DOORS identifiers will be larger than all manually created identifiers. Hope this helps, regards, Mathias

 

 

 

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

 

 

You may want a second script to make sure that a "Manual ID" for one object is not also an "Object Identifier" for another; otherwise you end up with two reqs with the same ID. You can mitigate that by convention, where a "Manual ID" doesn't look like an identifier; perhaps if your Prefix is "Sys_" your manuals could look like this: "Sys__33" or "Sys_00033".

-Louie